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FOREWORD 

This doia^Ki Sfsclfles the TELNET protocol and a number of approved options. 
It provlddl^rstsadsrd method of interfacing terminal devices and terminal- 
oriented pfocmstes to each other. It is envisioned that the protocol may also 
be used for terminal-terminal communication (’’Unking**) and process-process 
communication (distributed computation). 
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1.1 PwpiBfiK' Thlr'ttandard establishes criteria for the TELNET Protocol 
which suppOR# the standard method of Interfacing terminal devices and 
termlnal-*orlented processes to each other. 


1.2 Organization. This standard Introduces the TELNET Protocols role, 
defines the services provided to users, and specifies the mechanisms needed 
to support those services. This standard also Includes an appendix of options 
which can be Implemented In the TELNET Protocol and a glossary of terms and 
abbreviations. 


1.3 Application. This TELNET Protocol is mandatory for use In all DoD 
packet switching networks which connect or have the potential for utilizing 
connectivity across network and subnetwork boundaries and which require a 
virtual terminal service. The term network as used herein Includes Local 
Area Networks. 
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2. REFERENCED DOCUMENTS 

2*1 of docuMnf» Tho following docuaents of the issue In effect 

on date o# iavltotlof| for bids or request for proposal, fora a part of this 
standard to the extant specified herein. (The provisions of this paragraph 
are under consideration.) 

2.2 Other publications. The following docuasnts fora a part of this 
standard to the extent specified herein. Unless otherwise indicated, the 
Issue In effect on date of Invitation for bids or request for proposal shall 
apply. (The provisions of this paragraph are under consideration.) 
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3.1 

shall coap: 
are contained herein, 
tion.) 


3. DEFINITIONS 

tiai.:.e£''tenM. The definition of terns used in this standard 
fift>-STD-1037. Terns and definitions unique to MIL-STD-1782 
(The provisions of this paragraph are under conaidera- 


3.2 Definitions of acronyns used in this standard. The following acronyms 
used in this Military Standard are defined as follows: 


a. 

AO 

- Abort Output Comnand 

b. 

ATT 

- Are You There Conmand 

c. 

BS 

- Back Space 

d. 

CR 

- Carriage Return 

e. 

DDN 

- Defense Data Network 

f. 

DM 

- Data Mark 

g. 

DoD 

- Department of Defense 

h. 

DODIIS 

- DoD Intelligence Information System 

i. 

EC 

- Erase Character Command 

j. 

EL 

- Erase Line Command 

k. 

FF 

- Form Feed 

1. 

GA 

- Go-Ahead Command 

TS. 

HT 

- Horizontal Tab 

n. 

lAC 

- Interpret As Cooimand 

o. 

IBM 

- International Business Machines, Inc 

P* 

IP 

- Interrupt Process Command 

q* 

LF 

- Line Feed 

r. 

NVT 

- Network Virtual Terminal 

S s 

TCP 

- Transmission Control Protocol 

te 

TELNET 

- Telecommunications Network 

Ue 

VT 

- Vertical Tab 
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4 . TELNET PROTOCOL SPECIFICATION 


4.1 Th« purpose of the TELNET Protocol Is to provide a 

fairly ffenexlil• hf’^rectlonal. elght*‘blt byte oriented cosOuhlcatlons 
facility. Its priaary goal Is to allow a standard method of Interfacing 
temlnal devices and temlnal-orlented processes to each other. It Is 
envisioned that the protocol may also be used for temlnalHCenalnal coaaunl*- 
cation (‘’linking”) and process-i>rocess coaaunlcatlon (distributed coag>utatlon). 


The Appendices to this voluae contain DoD app roved and su 
options. 


rted Telnet 



4.2 General considerations. A TELNET connection Is a Transmission Control 
Protocol (TCP) connection used to transmit data with Interspersed TELNET 
control Information. The TELNET Protocol Is built upon three main Ideas: 
first, the concept of a Network Virtual Terminal; second, the principle of 
negotiated options; and third, a S3niimetrlc view of terminals and processes. 


4.2.1 Network Virtual Terminal (NVT). When a TELNET connection Is first 
established, each end Is assumed to originate and terminate at a Network 
Virtual Terminal (NVT). An NVT Is an Imaginary device which provides a 
standard, network-wide. Intermediate representation of a canonical terminal. 
This eliminates the need for "server” and "user” hosts to keep Information 
about the characteristics of each other's ter minals and terminal handlln 
conventions. 


s Intended to strike a balance between being overly restricted (not 
providing hosts a rich enough vocabulary for mapping Into their local 
character sets), and being overly inclusive (penalizing users with modest 
terminals). The "user" host is the host to which the physical terminal is 
normally attached, and the "server" host is the host which Is normally 
providing some service. As an alternate point of view, applic able even 
terrainal-to-termlnal or process -to-process c ommunications. 


4.2.2 Principle of negotiated options. The principle of negotiated options 
takes cognizance of the fact that many hosts will wish to provide additional 
services over and above those available within an NVT, and many users will 
have sophisticated terminals and would like to have elegant, rather than mini¬ 
mal, services. Independent of, but structured within the TELNET Protocol are 
various "options" that will be sanctioned and may be used with the "DO, DON'T, 
WILL, WON'T" structpre (discussed below) to allow a user and server to agree 
to use a more elaborate (or perhaps just different) set of conventions for 
their TELNET connection. Such options could include changing the character 
set, the echo mode, etc. The basic strategy for setting up the use of options 
Is to have either party (or both) Initiate a request that some option take 
effect. The other party may then either accept or reject the request. If 
the request Is accepted the option Immediately takes effect; If It Is rejected 
the associated aspect of the connection remains as specified for an NVT. 
Clearly, a party may always refuse a request to enable, and must never refuse 
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a requasC tiii^lsabla sone option since all parties must be prepared to support 
the NVT. tl» syntax of option negotiation has been set up so that If both 
parties rs^Mst sn option slDultaneously* each will see the other's request 
as the positive acknowledgnent of Its own. 

4,2.3 Symetry of the negotiation syntax . The sjrmisetry of the negotiation 
syntax can potentially lead to nontenalnating acknowledgnent loops ~ each 
party seeing the Incoming commands not as acknowledgments but as new requests 
which must be acknowledged. To prevent such loops, the following rules 
prevail: 

a. • party 

may not send out a "request" merely to announce what mode It Is 
in. 



Whenever one party sends an option command to a second party, 
whether as a request or an acknowledgment, and use of the option 
will have any effect on the process lng_of the data being sent 
from the first party to the 


time wlllelapsebetweeir^theHtrahXT v 
mission of a request and the receipt of an aciihowledgTOnt, 
which may be negative. Thus, a host may wish to buffer data, 
after requesting an option, until It learns whether the request 
is accepted or rejected, in order to hide the "uncertainty 
period" from the user. 


4.2.4 Use of options. 


to get the best po^ 


as each party attempts 
ST^ce from the other party. Beyond that, however, 


or example, the NVT, as will be 

explained later, uses a transmission discipline well suited to the many 
"line at a time" applications such as BASIC, but poorly suited to the many 
"character at a time" applications such as NLS. A server might elect to 
devote the extra processor overhead required for a "character at a time" 
discipline when it was suitable for the local process and would negotiate 
an appropriate option. However, rather than then being permanently burdened 
with the extra processing overhead, it could switch (l.e., negotiate) back 
to NVT when the detailed control was no longer necessary. It Is possible for 
requests initiated by processes to stimulate a nonterminating request loop 
if the process responds to a reJectlon__by nwrely re-requestlng the option 
To prevent such loops from occurring,I 


Operationally, this can mean the process Is running 
a different program, or the user has given another command, or whatever 
makes sense in the context of the given process and the given option. A 
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good rultt of tbu6 is that a re-raquett should only occur as a result of 
subsequent Inforaatlon from the otter end of the connection or fdien denanded 
by local huaan intervention. Option designers should not feel constrained by 
the sonewhat llsdLted syntax available for option negotiation. The Intent of 
the slaple syntax Is to oake it eesy to have options — since it Is corre¬ 
spondingly easy to profess ignorance about then. If sooe particular option 
requires a richer negotiation structura than possible within "DO. DON'T, 
vriLL, WON'T", the proper tack is to use "DO, DON'T, WILL, WON'T" to estabUsh 
that both parties understand the option, and once this is accomplished a 
more exotic syntax can be used freely. For exaaq>le, a party might send a 
request to alter (establish) liqe length.. If it is accepted,'Ifhen a different 
syntax can be used for actually negotiating the line length — such a "sub- 
negotlatlon" might Include fields for minimum allowable, maximum allowable 
and desired line lengths. The important concept Is that such expanded nego¬ 
tiations should never, begin.unti^^ some fic4cnr'(^ij|^ n.<iif|>jriatlon has 
established that both parties ardTIdpable ot parsing the exj^nded syntax. 


4.2.5 


sis. In sunmary, XXX, is sent,-by either party, to Indicate 

^re (offer) to b^tf |d1^|il£ng option XXX, DO XXX and DON'T 


that partjr S' 

XXX being Its positive and negative acknowledgments; similarly, DO XXX Is 
sent to Indicate a desire (request) that the other party (l.e. , the recipient 
of the DO) begin performing option XXX, WILL XXX and WON'T XXX being the 
positive and negative acknowledgments. Since the NVT Is what Is left when 
no options are enabled, the DON'T and WON'T responses are guaranteed to 
leave the connection In a stiate which both ends can handle. 



_"^As much as possible, the TELNET 

protdC'di’has been made server-user symmetrical so that It easily and naturally 
covers the user-user (linking) and server-server (cooperating processes) 
cases. It is hoped, but not absolutely required, that options will further 
this intent. In any case. It Is explicitly acknowledged that symmetry Is an 
operating principle rather than aq itehclfd; ^In* J.l|tandard TELNET options 
referenced In this document ard'dSnt’i'ihld In Appendices A-F. 


4.3 The Network Virtual Terminal . The Network Virtual Terniinal (NVT), Is 
a bl-directional character device. The NVf tes a printer and a keyboard.* 
The printer responds to incoming data and the keyboard produces outgoing 
data which is sent over the TELNET connection and. If "echoes" are jdwstced, 
to the NVT's printer as well. "Echoes" will not be expected to traverse the 
network (although options exist to enable a "rmsote" echoing mode of opera¬ 
tion, no host is required to Implemei^ this option). The code set Is seven- 
bit US ASCI I In an elght-blt field, except as modified herein. A^^'bde 
conversion and timing considerations are local problems and do not affect 
the NVT. 


4.3.1 Transmission of data . Alth ough a TELNET connection thr< mgh the 
netwo rk Is Int rinsically full dmol teJ 

_ That Is, unlest ate uttCli o^Tlons 
are negotiated to the co^trary,~^the following default conditions pertain to 
the transmission of data over the TQ,NET connection: 
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of data* Insofar as the availability of local buffer 



This signal could be generated 
either by a prdddll bk by a hunan user* The notlvatlon for this rule Is the 
high cost, to some hosts, of processing network Input Interrupts, coupled 
with the default NVT specification that "echoes" do not traverse the network. 
Thus, It is reasonable to buffer some amount of data at its source. Many 
systems take some processing action at the end of each Input line (even line 
printers or card punches frequently tend to work this way), so the transmis¬ 
sion should be triggered at the end of a line* On the other hand, a user or 
process may sometimes find It necessary or desirable to provide data which 
does not terminate at the end of a line; therefore Implementers are cautioned 
to provide methods of locally signaling that all buffered data should be 
transmitted Immediately. 


4.3.1.2 TELNET Go Ahead (GA) command* 








This rule Is not Intended to require chat 
Che TELNET GA command be sent fr6m a terminal at the end of each line, since 
server hosts do not normally require a special signal (in addition Co end-of- 
line or other locally-defined characters) In order to commence processing,.;:; 
Rather, the TELNET GA is designed to help a user's local host operate a 
physically half duplex terminal which has a "lockage” keyboard such as the 
IBM 2741. A description of this type of terminal luy help to explain the 
proper use of the GA command. The terminal-computer connection Is always 
under control of either the user or the computer. Neither can unilaterally 
seize control from the other; rather the controlling end must relinguish its 
control explicitly. At the terminal end, the hardware is constructed so as 
to relinquish control each time that a "line” Is terminated (l.e., when the 
"New Line" key is typed by the user). When this occurs, the attached (local) 
computer processes the input data, decides if output should be generated, 
and if not returns control to the terminal. If output should be generated, 
control is retained by the computer until all output has been transmitted. 

The difficulties of using this type of terminal through the network should 
be obvious. The "local" computer is no longer able to decide whether to 
retain control after seeing an end-of-llne signal or not; this decision can 
only be made by the "remote" computer which Is processing the data. There¬ 
fore, the TELNET GA command provides a mechanism whereby the "remote" (server) 
computer can signal the "local" (user) computer that i t is time to pass 
control to the user of the terminal. __ 

Note thiiiF ’W~the & commatui may r^liIF in 

the blocking of output, since the user is likely to assume Chat the transmit¬ 
ting system has paused, and therefore he will fail to turn the line around 
manually. 
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tw caution. Tha foregoing, ofcourse^doe^no^Moljrto 
idfireetlon of eoMualcatlon* 

Int need not "erer bd^^Mnt. Also, If the TEL^T conttec** 
tlM'"li~ilH|PMed tor process'*to**proce8s coauninlcatlon, GAs need not be 
sent in et^Mt direction* Finally, for teniinal**to-tenDlnal coanunicstlon, 
GAs any be required in neither, one, or both directions* If a host plans to 
support teralnel'^o-teminal coaaunlcatlon it is suggested that the host 
provide the user with a neans of aanuelly signaling that it is tine for a GA 
to be sent over the TELNET connection; this, however, is not a requirenent 
on the i^>leaenter of a TELNET process* The symaetry of the TELNET nodel 
requires an NVT at each end of the TELNET connection, at least conceptually. 



4.4 Standard representation of control functions. As stated in paragraph 
4.1, the primary goal of the TELNET protocol is the provision of a standard 
interfacing of terminal devices and temlnal-^rlented processes through the 
network. Early experiences with this type of interconnection have shown 
that certain functions are iaplelllBnted by most servers, but that the nethods 
of Invoking tlheee functions differ> widely. For a hunian user who interacts 
with several server systems, these differences are highly frustrating. 
telnet, therefore, ddfines a standard representatibn for five of these func¬ 
tions, as described below. These standard representations have standard, 
but not required, meanings (with the exception that the Interrupt Process 
(IP) function may be reoulr eH hv othar prnt-ftcQla whlc h-Ufte_TELNET); tha t is. 




4.4.1 Interrupt process (IP) . Many systems provide a function which 
suspends, interrupts, aborts, or terminates the operation of a user process. 
This function is frequently used when a user believes his process is in an 
unending loop, or when an unwanted process has been inadvertently activated. 
IP is the standard representation for invoking this function. It should be 
noted by implen^nters that IP may be required by other protocols which use 
TELNET, and therefore should be Implemented if these other protocols are to 
be supported. 


4.4.2 Abort output (AO). Many systems provide a function which allows a 
process, which is generating output, to run to completion (or to reach the 
same stopping point it would reach if running to completion) but without 
sending the output to the user's terminal. Further, this function typically 
clears any output already produced biit^not yet actually printed (or displayed) 
on the user's terminal. AO is the standard representation for invoking this 
function. For example, some subsystem might normally accept a user's command, 
send a long text string to the user's terminal in response, and finally sig¬ 
nal readiness to accept the next command by sending a "prompt" character 
(preceded by <CRXLF>) to the user's terminal. If the AO were received 
during the transmission of the text string, a reasonable implementation 
would be to suppress the remainder of the text string, but transmit the 
prompt character and the preceding <CRXLF>, (This is possibly in distinc¬ 
tion to the action which might be taken if an IP were received; the IP might 
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causa supiMllltfiftiiif tha taxt string and an exit fron the subsystea.) It 
should aarver systems which provide this function* that there 

nay be be f§|fc^i|Tlj|r“'' the system (In the network an4 the user'i local 
host) whleP«Hil#lii cleared; the sppropclete way to do this Is td transmit 
the "Synch" sfinal (described below) to the user system. 

4.4.3 Are you there (AYT). Many systems provide a function which provides 
the user with some visible (e.g., printable) evidence that the system is still 
up and running. This function may be invoked by the user when the system is 
unexpectedly "silent" for a long time, because of the unanticipated (by the 
user) length of a computation, an unusually heavy system load, etc. AYT Is 
the standard representation for Invoking this function. 

4.4.4 Erase character (EC). Many systems provide a function which deletes 
the last preceding undeleted character or "print position" from the stream 
of data being supplied by the user. A "print position" may contain several 
characters which are a result of overstrikes, or of sequences such as <charl> 
BS <char2>... This function is typically used to edit keyboard input when 
typing mistakes are made. EC is the standard representation for invoking 
this function. 

4.4.5 Erase line (EL). Many systems provide a function which deletes all 
the data in the current “line" of Input. This function is typically used 

to edit keyboard input. EL is the standard representation for invoking this 
function. 


4.5 The TELNET "Synch" signal . Most time-sharing systems provide mecha¬ 
nisms which allow a terminal user to regain control of a "rimaway" process; 
the IP and AO functions described above are examples of these mechanisms. 
Such systems, when used locally, have access to all of the signals supplied 
by the user, whether these are normal characters or special "out of band” 
signals such as those supplied by the teletype "BREAK” key or the IBM 2741 
"ATTN” key. This is not necessarily true when terminals are connected to 
the system through the network; the network's flow control mechanisms may 
cause such a signal to be buffered elsewhere, for example in the user's 
host. To counter this problem, the TELNET "Synch” mechanism is introduced. 


The Urgent notificationT which Is 'noF subject to the 
Tow control pertaining to the TELNET connection, is used to invoke special 
han dling of the data stream by the proce ss w hich recei ves i t. In this mode. 


The TELNET command DATA MARK (DM) is 
the synchrohf'iTBJ? mark flTTTiie data stream which indicates that any special 
signal has already .occurred and the recipient can return to normal processing 
of the data stream. The Synch is sent via the TCP send operation with the 
Urgent flag set and the DM as the last (or only) data octet. 
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••▼aral Synchs. When several Synchs are sent In rapid 
gent notifications asy be aerged* It Is not possible to 
tinea the nuaber received will be less than or equal the nuaber 


4.5.1 
successli 
count Hi 

sent. _ 

Indicates the end of Ur^ITt 

data before the DM Is foUM. TELNET should continue the special handling of 
the data strean until the DM Is found. If TCP Indicates wore Urgent data 
after the DM Is found. It can only be because of a subsequent Synch. TELNET 
should continue the special handling of the data stream until another DM Is 
found. 


' 4.5.2 Interesting signals . "Interesting" signals are defined to be: the 
TELNET standard representations of IP, AO, and AYT (but not EC or EL); the 
local analogs of these standard representations (If any); all other TM<NET 
commands; ocher site-defined signals which can be acted on without delaying 
the scan of the data stream. 


4,5.3 One effect of the Synch mechanism. Since one effect of the SYNCH 
mechanism Is the discarding of essentially all characters (e xcept TELNET 
comma nds)_bet ween the sender nf rhe Synch and Its recipient. 


For example. If a user at a terminal causes an AO to be transmitted, the 
server which receives the AO (If it provides that function at all) should 
return a Synch to the user. 


4,5,4 TELNET command requirement. Just as the TCP Urgent notification is 
needed at the TELNET level as an out-of-band signal, so other protocols 
which make use of TELNET may require a TELNET command which can be viewed as 
an out-of-band signal at a different level. By convention the sequence [IP, 
Synch] Is to be used as such a signal. For example, suppose that some other 
protocol, which uses TELNET, defines the character string STOP analogously 
to the TELNET command AO. Imagine that a user of this protocol wishes a 
server to process the STOP string, but the connection Is blocked because the 
server Is processing other commands. The user should instruct his system to: 


a. Send the TELNET IP character; 

b. Send the TELNET SYNC sequence, that is: Send the Data Mark (DM) 
as the only character in a TCP urgent mode send operation; 

c. Send the character string STOP; and 

d. Send the other protocol's analog of the TELNET DM, If any. 

The user (or process acting on his behalf) must transmit the TELNET SYNCH 
sequence of step b above to ensure that the TELNET IP gets through to the 
server's TELNET interpreter. The Urgent should wake up the TELNET process; 
the IP should wake up the next higher level process. 

4,6 The NVT printer and keyboard . 
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4.6.1 .JHlIli pJMBMr codea. The NVT printer hee an unspecified carriage 
width end^HEleflqitli and can produce representations of all 95 USASCIl 
graphics 32 through 126). Of the 33 USASCIl control codes (0 through 

31 and ITT^^^ad the 128 uncovered codes (128 through 255), the following 
have specified meaning to the NVT printer: 

NAME CODE MEANING 

a. NULL (NUL) 0 No Operation 

b. Line Feed (LF) 10 Moves the printer to the next 

print line, keeping the same 
horizontal position. 

c. Carriage Return (CR) 13 Moves the printer to the left 

margin of the current line. 

In addition, the following codes shall have defined, but not required, effects 
on the NVT printer. Neither end of a TELNET connection may assume that the 
other party will take, or will have taken, any particular action upon receipt 
or transmission of the following: 

NAME CODE MEANING 

d. BELL (BEL) 7 Produces an audible or visible 

signal (which does NOT move the 
print head). 

e. Back Space (BS) 8 Moves the print head one character 

position towards the left margin. 

f. Horizontal Tab (HT) 9 Moves the printer to the next 

horizontal tab stop. It remains 
unspecified how either party 
determines or establishes where 
such tab stops are located. 

g. Vertical Tab (VT) 11 Moves the printer to the next 

vertical tab stop. It remains 
unspecified how either party 
determines or establishes where 
such tab stops are located. 

h. Form Feed (FF) 12 Moves the printer to the top of 

the next page, keeping the same 
horizontal position. 

All remaining codes do not cause the NVT printer to take any action. 
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4.6.1.1 code u»c. The sequence "OR LF", as defined, will 

cause the lIV to be positioned at the left oergln of the next print line (as 
would, for <neaple» the sequence "LFCR”). However, nany systens and termi¬ 
nals do not treat'd and LF Independently, and will have to go to some effort 
to simulate their effect. (For example, some terminals do not have a CR 
Independent of the LF, but on such terminals it may be possible to simulate 
a CR by backspacing.) Therefore, the sequence "CR LF" must be treated as a 
single "new line" character and used whenever their combined action is 
intended; the sequence "CR NUL" must be used where a carriage return alone 
is actually desired; and the CR character must be avoided in other contexts. 
This rule gives assurance to systems which must decide whether to perform a 
"new line" function or a multiple-backspace that the TELNET stre am cont 
a character following a CR that will allow a rational decision. 



_ _Even though it may be 

kn6«ra in some situations (e.g., with remote echo and suppress go ahead options 
in effect) that characters are not being sent to an actual printer, nonethe¬ 
less, for the sake of consistency, the protocol requires that a NUL be 
Inserted following a CR not followed by a LF in the data stream. The converse 
of this is that a NUL received in the data stream after a CR (in the absence 
of options negotiations which explicitly specify otherwise) should be stripped 
out prior to applying the NVT to.local character set mapping. 


4.6.1.2 USASCII code generation. The NVT keyboard has keys, or key combi¬ 
nations, or key sequences, for generating all 128 USASCII codes. Note that 
although many have no effect on the NVT printer, the NVT keyboard is capable 
of generating them. 


4.6.1.3 Additional codes . In addition to these codes, the NVT keyboard 
shall be capable of generating the following additional codes which, except 
as noted, have defined, but not required, meanings. The actual code assign¬ 
ments for these "characters" are in the TELNET Command section, because they 
are viewed as being, in some sense, generic and should be available even 
when the data stream is interpreted as being some other character set. 

4.6.1.3.1 Synch . This key allows the user to clear his data path to the 
other party. The activation of this key causes a DM (see command section) 
to be sent in the data stream and a TCP Urgent notification is associated 
with it. The pair DM-Urgent is to have required meaning as defined previously. 

4.6.1.3.2 Break (BRK). This code is provided because it is a signal 
outside the USASCII set which is currently given local meaning within many 
systems. It is Intended to indicate that the Break Key or the Attention Key 
was hit. Note, however, that this is Intended to provide a i29th code for 
systems which require it, not as a synonym for the IP standard representation. 

4.6.1.3.3 Interrupt process (IP). Suspend, interrupt, abort or terminate 
the process to which the NVT is connected. Also, part of the out-of-band 
signal for other protocols which use TELNET. 
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4.6.1.1 
nm to o 
Synch Co 



ootPut (AO)J . 


Allow Che current process Co (appear Co) 
. hot do not (send Its output to Che user. Also, send a 


4.6.1.3.jf^ ^fte you there (AYT). Send back to the NVT some visible (l.e., 
printable) evidence Chat Che AYT was received. 

4.6.1.3.6 Erase character (EC). The recipient should delete the last 
preceding undeleted character or "print position" from the data stream. 


4.6.1.3.7 Erase line (EL). The recipient should delete characters from 
Che data stream back to, but not Including, the last "CR LF" sequence sent 
over the TELNET connection. 


4.6.1.3.8 Intent of additional codes. The spirit of these "extra" keys, 
and also the printer format effectors. Is that they should represent a 
natural extension of the mapping that already must be done from "NVT" into 
"local". Just as the NVT data byte 68 (104 octal) should be mapped Into 
whatever the local code for "uppercase D" is, so the EC character should be 
mapped Into whatever the local "Erase Character" function Is. Further, Just 
as the mapping for 124 (174 octal) Is somewhat arbitrary In an environment 
that has no "vertical bar" character, the EL character may have a somewhat 
arbitrary mapping (or none at all) If there is no local "Erase Line" facility. 
Similarly for format effectors: If the terminal actually does have a "Verti¬ 
cal Tab", then the mapping for VT is obvious, and only when the terminal 
does not have a vertical tab should the effect of VT be unpredictable. 


TELNET comma nd structure. All TELNET commands consist of at least 
two byte sequence: _ 

fThe commands dealing with option negotiation 
are three byte sequencesT^the third byte being the code for the option refer¬ 
enced. This format was chosen so that as more comprehensive use of the 
"data space" is made — by negotiations from the basic NVT, of course — 
collisions of data bytes with reserved command values will be minimized, all 


such collisions requiring the Inc onyenlenc 
the data bytes into the stream. 


and Inefficiency, of "escaping' 



4.7.1 TELNET commands defined . The following are the defined TELNET 
commands. Note that these codes and code sequences have the Indicated meaning 
only when Immediately preceded by an lAC. 




CODE 

SE 


240 

NOP 


241 

Data Mark 


242 


End of subnegotiation parameters. 
No operation. 

The data stream portion of a Synch. 
This should always be accompanied 
by a TCP Urgent notification. 
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- ^3^3 243 

*n^“- 

Process ' 244 


■■- , 'fi, . 

f. Abort output 245 

g. Are You There 246 

h* Erase character 

I. Erase Line %3?o 248 

J. Go ahead %37( 249 

k. SB %37X 250 


373 


1. WILL (option code) 251 



m. WON'T (option code) 252 


^ ^ n. DO (option code) 253 

io2n> 


^oyi‘o °* 


DON'T (option code) 254 


NVT character BRK« 

The fun'ctlon IP. 

The function AO. 

The function AYT. 

The function EC. 

The function EL. 

The GA signal. 

Indicates that what follows Is 
subnegotiation of the Indicated 
option. 

Indicates the desire to begin per- 
foiming, or conflroatlon that you 
are now perfomlng, the Indicated 
option. 

Indicates the refusal to perform, or 
continue perfomlng, the Indicated 
option. 

Indicates the request that the other 
party perform,-lor confirmation that 
you are expecting the other party to 
perform, the Indicated option. 

Indicates the demand that the other 
party stop performing, or confirmation 
that you are no longer expecting the 
other party to perfom, the Indicated 
option. 


p. lAC 255 Data Byte 255. 

4.8 Connection establishment. The TELNET TCP connection is established 
between the user's port U and the server's port L. The server listens on 
Its well known port L for such connections. Since a TCP connection Is full 
duplex and Identified by the pair of ports, the server can engage In many 
simultaneous connections Involving Its port L and different user 
ports U. 


4.8.1 Port assignment . When used for remote user access to service hosts 
(l.e., remote terminal access) this protocol Is assigned server port 23 (27 
octal). That Is L-23. 
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Custodians: 

Azmf - CR 
Nayy - OM 
Air Force - 90 


Preparing Activity 
DCA - DC 

(Project IPSC-0176- 


Revlew Activities: 

Army - SC, CR, AD 

Navy - AS, YD, MC, (W, ND, NC, EC, SA 
Air Force - 1, 11, 13, 17, 99, 90 


Other Interest: 
NSA - NS 
TRI-TAC-TT 


■01 
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apfemdix a 



TELMBT BlIttUlT TRANSMISSION 


1. Coonand nane and code* 


TRANSMIT-BINARY 0 

2. Coamand meanings, 

2.1 lAC WILL TRANSMIT-BINART. The sender of this coanand REQUESTS perais-* 
slon to begin transalttlng, or conflras that It will now begin transalttlng 
characters which are to be Interpreted as 8 bits of binary data by the receiver 
of the data. 


2.2 lAC WON’T TRANSMIT-BINARY. If the connection Is already being oper¬ 
ated In binary transalsslon aode» the sender of this comaand DEMANDS to 
begin transalttlng data characters which are to be Interpreted as standard 
NVT ASCII characters by the receiver of the data. If the connection Is not 
already being operated in binary transalsslon aode, the sender of this coa- 
aand REFUSES to begin transalttlng characters which are to be Interpreted as 
binary characters by the receiver of the data (l.e.. the sender of the data 
deaands to continue transalttlng characters In Its present aode). A connec¬ 
tion Is belna operated In binary transalsslon aode only when one party has 
requested It and the other has acknowledged It. 

2.3 lAC DO TRANSMIT-BINARY. The sender of this coaaand REQUESTS that the 
sender of the data start transalttlng. or conflras that the sender of data 
Is expected to transmit, characters which are to be Interpreted as 8 bits of 
binary data (l.e., by the party sending this command). 

2.4 lAC DON'T TRANSMIT-BINARY. If the connection la already being operated 
In binary transmission mode, the sender of this comaand DEMANDS that the 
sender of the data start transmitting characters which are to be Interpreted 
as standard NVT ASCII characters by the receiver of the data (l.e., the party 
sending this command). If the connection Is not already being operated In 
binary transmission mode, the sender of this command DEMANDS that the sender 
of data continue transmitting characters which are to be Interpreted in the 
present mode. A connection Is being operated In binary transmission mode 
only when one party has requested It and the other has acknowledged It. 

3. Default. 


WON’T TRANSMIT-BINARY 
DON’T TRANSMIT-BINARY 

The connection Is not operated In binary mode. 
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4. M6tl^>Wtl<m for the option. It Is soiMtlmss useful to have available a 
binary transaisslon path within TELNET without having to utilize one of the 
wore efflclMt, higher level protocols providing binary transadsslon (such 
as the File Transfer Protocol). The use of the lAC prefix within the basic 
TELNET protocol provides the option of binary transmission in a natural way, 
requiring only the addition of a nechanlse by which the parties Involved can 
agree to INTERPRET the characters transmitted over a TELNET connection as 
binary data. 

5. Description of the option. With the binary transmission option in 
effect, the receiver should Interpret characters received from the transmitter 
which are not preceded with lAC as 8 bit binary data, with the exception of 
lAC followed by lAC which stands for the 8 bit binary data with the decimal 
value 255. lAC followed by an effective TELNET command (plus any additional 
characters required to complete the command) Is still the command even with 
the binary transmission option In effect. lAC followed by a character which 
Is not a defined TELNET command has the same meaning as IA.C followed by NOP, 
although an lAC followed by an undefined command should not normaliy be sent 
in this mode. 

6. Implementation suggestions . It Is foreseen that log>lementations of 
the binary transmission option will choose to refuse some other options 
(such as the EBCDIC transmission option) while the binary transmission option 
Is in effect. However, If a pair of hosts can understand being In binary 
transmission mode simultaneous with being in, for example, echo mode, then 

It is alright if they negotiate that combination. The meanings of WON'T 
and DON'T are dependent upon whether the connection is presently being oper¬ 
ated in binary mode or not. Consider a connection operating In EBCDIC mode 
which involves a system which has chosen not to Implement any knowledge of 
the binary command. If this system were to receive a DO TRANSMIT-BINA.RY, it 
would not recognize the TRANSMIT-BINARY option and therefore would return a 
WON'T TRANSMIT-BINARY. If the default for the WON'T TRANSMIT-BINARY were 
always NVT ASCII, the sender of the DO TRANSMIT-BINARY would expect the 
recipient to have switched to NVT ASCII, whereas the receiver of the DO 
TRANSMIT-BINARY would not make this Interpretation. Thus, we have the rule 
that when a connection is not presently operating in binary mode, the default 
(i.e., the interpretation of WON'T and DON'T) is to continue operating in 
the current mode, whether that is NVT ASCII, EBCDIC, or some other mode. 

This rule, however, is not applied once a connection is operating in a binary 
mode (as agreed to by both ends); this would require each end of the connec¬ 
tion to maintain a stack, containing all of the encoding-method transitions 
which had previously occurred on the connection, in order to properly inter¬ 
pret a WON'T or DON'T. Thus, a WON'T or DON'T received after the connection 
is operating in binary mode causes the encoding method to revert to NVT 
ASCII. 
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7* aoda* It should be renenbered that a TELNET connec¬ 

tion ii|^^E|||^ealiiiiuaircatlon channel* The binary transolsslon node Bust 
be. nes«C^B||^^i|arately for each direction of data flow. If that Is deilred. 
lapleasstttiflPK"of the binary transadsslon option, as Is the case with lapleoen- 
tatlons oi all other TELNET options, oust follow the loop preventing rules 
given In,the General Considerations section of the TELNET Protocol Specifica¬ 
tion. Consider now some Issues of binary transolsslon both to and fron both 
a process and a temlnal: 

7*1 Binary transolsslon from a terolnal* The Inplementer of the binary 
transolsslon option should consider how (or whether) a terolnal transolttlng 
over a TELNET connection with binary transolsslon In effect is allowed to 
generate all eight bit characters. Ignoring parity considerations, etc., on 
input froo the temlnal* 

7.2 Binary transolsslon to a process. The Implementer of the binary 
transolsslon option should consider how (or whether) all charactere are 
passed to a process receiving over a connection with binary transmission In 
effect. As an example of the possible problem, TOPS-20 Intercepts certain 
characters (e.g., ETX, the terminal control-C) at monitor level and does not 
pass them to the process* 

7.3 Binary transmission from a process. The Implementer of the binary 
transmission option Should consider how (or whether) a process transmitting 
over a connection with binary transmission In effect Is allowed to send all 
eight bit characters with no characters Intercepted by the monitor and changed 
to other characters. An example of such a conversion may be found In the 
TOPS-20 system where certain non-prlntlng characters are normally converted 

to a Circumflex (up-arrow) followed by a printing character. 

7.4 Binary transmission to a terminal . The Implementer of the binary 
transmission option should consider how (or whether) all characters received 
over a connection with binary transmission In effect are sent to a local 
terminal. At Issue may be the addition of timing characters normally Inserted 
locally, parity calculations, and any normal code conversion. 


18 



APPENDIX B 


MIL-6TD-1782 
10 May 1984 


1 . 


2 . 


2.1 lAC WILL ECHO. The sender of this comaand REQUESTS to begin, or con¬ 
firms that It will now begin, echoing data characters It receives over the 
TELNET connection back to the sender of the data characters. 

2.2 lAC WON’T ECHO . The sender of this command DEMANDS to stop, or refuses 
to start, echoing the data characters It receives over the TELNET connection 
back to the sender of the data characters. 

2.3 lAC DO ECHO . The sender of this command REQUESTS that the receiver 
of this command begin echoing, or confirms that the receiver of this command 
is expected to echo, data characters It receives over the TELNET connection 
back to the sender. 

2.4 lAC DON'T ECHO . The sender of this command DEMANDS the receiver of 
this command stop, or not start, echoing data characters it receives over 
the TELNET connection. 

3. Default. 


telnet echo (VTION 


Command name and code. 
ECHO 1 

Command meanings . 


WON’T ECHO 
DON’T ECHO 

No echoing Is done over the TELNET connection. 

4. Motivation for the option. The NVT has a printer and a keyboard which 
are nominally Interconnected so that “echoes" need never traverse the network; 
that is to say, the NVT nominally operates in a mode where characters typed 
on the keyboard are (by some means) locally turned around and printed on the 
printer. In highly Interactive situations it is appropriate for the remote 
process (command language interpreter, etc.) to which the characters are 
being sent to control the way they are echoed on the printer. In order to 
support such Interactive situations, it is necessary that there be a TELNET 
option to allow the parties at the two ends of the TELNET connection to 
agree that characters typed on an NVT keyboard are to be echoed by the party 
at the other end of the TELNET connection. 
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5* P—the option. When the echoing option Is In effect, the 
party st fjyj|iii1 psrfnmlnj fhn echoing Is expected to transsdt (echo) data 
characters^fr'receives back to the sender of the data characters. The option 
does not require that the characters echoed be exactly the characters received 
(for exanple, a number of systems echo the ASCII ESC character with something 
other than the BSC character). When the echoing option Is not In effect, the 
receiver of data characters should not echo then back to the sender; this, 
of course, does not prevent the receiver from responding to data characters 
received. The normal TELNET connection Is two way. That Is, data flows In 
each direction on the connection Independently; and neither, either, or both 
directions may be operating simultaneously In echo node. There are five 
reasonable inodes of operation for echoing on a connection pair: 



Neither end echoes 



One end echoes for itself 



One end echoes for the other 



Both ends echo for themselves 
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th« capability to daclda on whether or not either end 
will eehe^SKtiM otlMr* It does not, however, provide any control over 
whether oc'^&'-an end echoes for Itself; this ^clslon oust be left to the 
sole dlscrsISte of the systems at each end (although they nay use Information 
regarding the state of "remote** echoing negotiations In making this decision). 
If BOTH hosts enter the node of echoing dtaracters transmitted by the other 
host, then any character transmitted In either direction will be "echoed" 
back and forth Indefinitely. Therefore, care should be taken In each Imple¬ 
mentation that If one site Is echoing, echoing Is not permitted to be turned 
on at the other. As discussed In Section 4, both parties to a full-duplex 
TELNET connection Initially assume each direction of the connection Is being 
operated In the default mode which Is non-edio (non-echo Is not using this 
option, and the same as DON'T ECHO, WON'T ECHO). If either party desires 
himself to echo characters to the other party or for the other party to echo 
characters to him, that party gives the appropriate coousand (WILL ECHO or DO 
ECHO) atkl waits (and hopes) for acceptance of the option. If the request to 
operate the connection in echo mode is refused, then the connection continues 
to operate In non-echo mode. If the request to operate the connection in 
echo mode Is accepted, the connection Is operated In echo mode. After a 
connection has been changed to echo mode, either party may demand that It 
revert to non-echo mode by giving the appropriate DON'T ECHO or WON'T ECHO 
command (which the other party must confirm thereby allowing the connection 
to operate in non-echo mode). Just as each direction of the TELNET connec¬ 
tion may be put In remote echoing mode independently, each direction of the 
TELNET connection must be removed from remote echoing mode separately. 

6. Implementation of the option . Implementations of the echo option, as 
implementations of all other TELNET options, must follow the loop preventing 
rules given in the General Considerations section of the TELNET Protocol 
Specification. Also, so that switches between echo and non-echo mode can be 
made with minimal confusion (momentary double echoing, etc.), switches in 
mode of operation should be made at times precisely coordinated with the 
reception and transmission of echo requests and demands. For instance, if 
one party responds to a DO ECHO with a WILL ECHO, all data characters received 
after the DO ECHO should be echoed and the WILL ECHO should immediately pre¬ 
cede the first of the echoed characters. The echoing option alone will nor¬ 
mally not be sufficient to effect what la commonly understood to be remote 
computer echoing of characters typed on a terminal keyboard—the SUPPRESS-GO 
AHEAD option will normally have to be Invoked in conjunction with the ECHO 
option to effect character-at-a-tlme remote echoing. 

6.1 A sample implementation of the option . The following is a description 
of a possible implementation for a simple user system called "UHOST". A 
possible implementation could be that for each user terminal, the UHOST 
would keep three state bits: whether the terminal echoes for itself (UHOST 
ECHO always) or not (ECHO mode possible), whether the (human) user prefers 
to operate in ECHO mode or in non-ECHO mode, and whether the connection from 
this terminal to the server is in ECHO or non-ECHO mode. We will call these 
three bits P(hy8ical), D(eslred), and A(ctual). When a terminal dials up the 
UHOST the P-bit is set appropriately, the D-bit is set equal to it, and the 
A—bit la set to non-ECHO. The P—bit and D-blt may be manually reset by 


21 




MIL-STD-1782 
10 May 1984 


direct eoiipeaie If the user so desires. For exaeple, a user In Hawaii on a 
"full-duploi^ hereieel, would choose not to operate In ECHO node, regardless 
of the preCecence of e nelnland server. He should direct the UHOST to change 
his D-ldt froB ICBO to nott'-BGHO. When a connection Is opened from the UHOST 
terminal to a server, the UHOST would send the server a DO ECHO command If 
the MIN (with non'^CHO less than ECHO) of the P** and D-blts Is different 
from the A-blt. If a WON'T ECHO or HILL ECHO arrives from the server, the 
UHOST will set the A~blt to the MIN of the received request, the P-blt, and 
the D-blt. If this changes the state of the A>blt, the UHOST will send off 
the appropriate acknowledgment; If It does not, then the UHOST will send off 
the appropriate refusal If not changing meant that It had to deny the request 
(i.e., the MIN of the P-*and D-blts was less than the received A-request). tf 
while a connection Is open, the UHOST terminal user changes either the P'-blt 
or D-blt, the UHOST will repeat the above tests and send off a DO E(S0 or 
DON'T ECHO, If necessary. When the connection is closed, the UHOST would 
reset the A-bit to Indicate UHOST echoing. While the UHOST's Implementation 
would not Involve DO ECHO or DON'T ECHO commands being sent to the server 
except when the connection Is opened or the user explicitly changes hls 
echoing mode, bigger hosts might invoke such mode switches quite frequently. 
For Instance, while a llne-at-a-tlme system were running, the server might 
attempt to put the user in local echo mode by sending the WON'T ECHO command 
to the user; but while a character-at-a-tlme system were running, the server 
might attempt to invoke remote echoing for the user by sending the WILL ECHO 
command to the user. Furthermore, while the UHOST will never send a WILL 
ECHO command and will only send a WON'T ECHO to refuse a server sent DO ECHO 
command, a server host might often send the WILL and WON'T ECHO commands. 


22 



MIL-STD-1782 
10 May 1984 


1 . 



APPENDIX C 

tQL.NET SUPPRESS GO AHEAD OPTION 
and code. 


SUPPRESS-GO-AHEAD 3 


2. Command meanings . 

2.1 lAC WILL SUPPRESS-GO-AHEAD . The sender of this command requests 
permission to begin suppressing transmission of the TELNET GO AHEAD (GA) 
character when transmitting data characters« or the sender of this command 
confirms It will now begin suppressing transmission of GAs with transmitted 
data characters. 


2.2 lAC WON’T SUPPRESS-GO-AHEAD . The sender of this command demands to 
begin transmitting, or to continue transmitting, the GA character when trans¬ 
mitting data characters. 

2.3 lAC DO SUPPRESS-GO-AHEAD . The sender of this commannd requests that 
the sender of data start suppressing GA when transmitting data, or the sender 
of this command confirms that the sender of data Is expected to suppress 
transmission of GAs. 


2.4 lAC DON'T SUPPRESSS-GO-AHEAD . The sender of this command demands 
that the receiver of the command start or continue transmitting GAs when 
transmitting data. 

3. Default. 


WON’T SUPPRESS-GO-AHEAD 
DON'T SUPPRESS-GO-AHEAD 
Go aheads are transmitted. 

4. Motivation for the option . While the NVT nominally follows a half dup¬ 
lex protocol complete with a GO AHEAD signal, there is no reason why a full 
duplex connection between a full duplex terminal and a host optimized to 
handle full duplex terminals should be burdened with the GO AHEAD signal. 
Therefore, It is desirable to have a TELNET option with which parties in¬ 
volved can agree that one or the other or both should suppress transmission 
of GO AHEADS. 

5. Description of the option. When the SUPPRESS-GO-AHEAD option is in 
effect on the connection between a sender of data and the receiver of the 
data, the sender need not transmit GAs. It seems probable that the parties 
to the TELNET connection will suppress GO AHEAD in both directions of the 
TELNET connection if GO AHEAD Is suppressed at all; but, nonetheless, it 
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AHEAD 0|p< 
recalirttA 



both dlrectlona independently. With the SUPPRESS-00- 
the lAC GA conend ehould be treated ee e NOP If 
6A ehould not noraelly be eent in this eode. 


6. lepl eeentetion considerations . As the SUPSESS*K>0~AHBAD option is sort 
of the opposite of e line at a tliM mode. the sender of data which is suppres¬ 
sing 00 AHEADs should attempt to actually transmit characters as soon as 
possible (i.e.. with minimal buffering) consistent with any other agreements 
which are in effect. In many TELNET implementations it will be dMirable to 
couple the SUPFRESS-GOnAHEAO option to the echo option so that when the echo 
option is in effect, the SUPPRESS-GO-AHEAD option is in effect simultaneously: 
both of these options will normally have to be in effect simultaneously to 
effect what is commonly understood to be character at a time echoing by the 
remote computer. 
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APPEHDIX D 

telnet status option 


1« CoBBaand nane and code. 

STATUS 5 

2. CoBBBand meanings. This option applies separately to each direction of 
data flow. 

2.1 lAC WILL STATUS . The sender of WILL status agrees to send status 
Information, spontaneously or In response to future requests. 

2.2 lAC WON'T STATUS . Sender refuses to carry on any further discussion 
of the current status of options. 

2.3 lAC DO STATUS . The sender of DO wishes to be able to send request 
for status of In option Information or confirms that he Is willing to send 
such requests. 

2.4 lAC DON’T STATUS . Sender refuses to carry on any further discussion 
of the current status of options. 

2.5 lAC SB STATUS SEND lAC SE . Sender requests receiver to transmit his 
(the receiver’s) perception of the current status of TELNET options. The 
code for SEND is 1. 

2.6 lAC SB STATUS IS ... lAC SE . Sender Is stating his perception of the 
current status of TELNET options. The code for IS is 0. 

3. Default. 


DON'T STATUS, WON’T STATUS 

The current status of options will not be discussed. 

4. Motivation for the option . This option allows a user/process to verify 
the current status of TELNET options (e.g., echoing) as viewed by the person/ 
process on the other end of the TELNET connection. Simply renegotiating 
options could lead to the nonterminating request loop problem discussed In 
paragraph 4.2.3. This option fits Into the normal structure of TELNET options 
by deferring the actual transfer of status Information to the SB command. 

5. Description of the option . WILL and DO are used only to obtain and 
grant permission for future discussion. The actual exchange of status Informa¬ 
tion occurs within option subcommands (lAC SB STATUS...). Once the two hosts 
have exchanged a WILL and a DO, the sender of the WILL STATUS is free to 
transmit status Information, spontaneously or In response to a request from 
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tha ■aiwltr TOt if worst* this way load to trananlttlng the Infomatlon 

twice. Oalf:;iS^-a«ate of the DO way sand requests (UC SB STATUS SEND UC 
SE) and onl^^Aa saadsT of tlM WILL tey transalt actual status Infomatlon 
(within an lAiG SB STATUS IS ... lAC SE cosnand). IS has the subconmands 
WILL* DO and SB. They are used EXACTLY as used during the actual negotiation 
of TELNET options* except that SB Is teralnated with SB* rather than lAC SE. 
Transmission of SE* as a regular data byte* Is accoiq>llshed by doubling the 
byte (SE SE). Options that are not eiq>lleltly described are assumed to be 
in their default states. A single lAC SB STATUS IS...IAC SE describes the 
condition of ALL options. 

6. Example of option application. The following is an example of use of 
the option: 

Hostl: lAC DO STATUS 

Ho8t2: lAC WILL STATUS 

(Host2 is now free to send status Information at any time. 
Solicitations from Hostl are NOT necessary. This should not 
produce any dangerous race conditions. At worst, two IS's will 
be sent.) 

Hostl (perhaps): lAC SB STATUS SEND lAC SE 

Host2 (the following stream is broken into multiple lines only for 
readability. No carriage returns are implied.): 

lAC SB STATUS IS 

WILL ECHO 

DO SUPPRESS-GO-AHEAD 
WILL STATUS 
DO STATUS 
lAC SE 

Explanation of Ho8t2's perceptions: It is responsible for echoing 
back the data characters it receives over the TELNET connection; 
it will not send Go-Ahead signals; it will both issue and request 
Status information. 
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APPENIX E 

TELNET TIMING MARK OPTION 

1. Coamand nane and code. 

TIMING-MARK 6 

2. Command meanings* 

2.1 lAC WILL TIMING-MARK, The sender of this command ASSURES the receiver 
of this command that it is inserted in the data stream at the "appropriate 
place" to Insure synchronization with a DO TIMING-MARK transmitted by the 
receiver of this command, 

2.2 lAC WON'T TIMING-MARK. The sender of this command REFUSES to insure 
that this command is inserted in the data stream at the "appropriate place" 
to insure synchronization. 

2.3 lAC DO TIMING-MARK , The sender of this command REQUESTS that the 
receiver of this command return a WILL TIMING-MARK in the data stream at the 
"appropriate place" as defined in paragraph 11.4 below. 

2.4 lAC DON’T TIMING^IARK , The sender of this command notifies the 
receiver of this command that a WILL TIMING-MARK (previously transmitted by 
the receiver of this command) has been IGNORED, 

3. Default . 

WON'T TIMING-MARK, DON'T TIMING-MARK 

l.e.. No explicit attempt is made to synchronize the activities at the two 
ends of the TELNET connection. 

4. Motivation for the option . It is sometimes useful for a user or pro¬ 
cess at one end of a TELNET connection to be sure that previously transmitted 
data has been completely processed, printed, discarded, or otherwise disposed 
of. This option provides a mechanism for doing this. In addition, even if 
the option request (DO TIMING-MARK) is refused (by WON'T TIMING-MARK) the 
requester is at least assured that the refuser has received (if not processed) 
all previous data. 

5. Examples of option application . As an example of a particular applica¬ 
tion, imagine a TELNET connection between a physically full duplex terminal 
and a "full duplex" server system which permits the user to "type ahead" 
while the server is processing previous user input. Suppose that both sides 
have agreed to Suppress Go Ahead and that the server has agreed to provide 
echoes. The server now discovers a command which it cannot parse, perhaps 
because of a user typing error. It would like to throw away all of the 
user's "type-ahead" (since failure of the parsing of one command is likely 
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to load to Ineorroet rooults if subooquont coaaands ara azacutad), aand tha 
uaar as raauaa intarpratatlon of caaaanda which tha uaar 

typad Cfii arror ■aaaaga* If tha uaar wara local, tha ayataa 

would h» jMlphr-dliaaard tha huffarad Input; bu| input nay ba buffarad in 
tha uaar'sKIft dr alaawhara* TlMrafora, tte aarvar wight aand a DO TIMIliG*- 
MUtK and h^iii to racoiwa a WILL TIMIIiG-MiRK froo tha uaar at tha "appropriata 
placo" in tha data atraaai* Tha "appropriata placa" (in abaanea of othar 
inforaation) ia elaarly juat bafora tha firat charactar which tha uaar typad 
aftar aaaing tha arror oaaaaga* That ia, it ahould appaar that tha tining 
■ark waa "printad" on tha uaar'a taminal and that, in raaponaa, tha uaar 
typad an anawaring tiaing nark. Naxt, auppoaa that tha uaar In tha axaaple 
abova raaliaad that ha had niaapallad a cooaand, raalized that tha aarver 
would aand a DO TIMIII6*4(iRK, and wantad to atart "typing ahaad* again withput 
waiting for thia to occur* Ha night than inatruct hia own ayatan to aand a 
WILL TIHING-KARK to tha aarvar and than bagin "typing ahaad" again. (laple- 
nantera ahould remember that tha uaar'a own ayatan nuat renenbar that it 
aent tha WILL TIMING-MARK ao aa to diacard tha DO/DON'T TIMING-MARK whan it 
evantually arrivaa.) Thua, in thia caaa the "appropriata placa" for tha 
inaertion of the WILL TIMING-MARK la the place defined by the uaar* In both 
of tha exanplea abova, it ia the reaponalblllty of the ayatan which trananlta 
the DO TIMING-MARK to diacard any unwanted charactera; the WILL TIMING-MARK 
only provldea help in deciding which charactera are "unwanted". 

6. Deacriptlon of the option * Suppoae that Proceaa A of Figure B-l wlahea 
to aynchronlze with B* The DO TIMING-MARK la aent fron A to B* B can refuae 
by replying WON'T TIMING-MARK, or agree by pemlttlng the tining nark to 
flow through his "outgoing" buffer, BUF2. Then, Instead of delivering It to 
the terminal, B will enter the mark Into his "Incoming" buffer BUFl, to flow 
through toward A. When the mark has propagated through B's Incoming buffer, 

B returns the WILL TIMING-MARK over the TELNET connection to A. 


raoccaa a mNCTeoMMctian paoccaa a teamwial 



<NVT PROCESS! 


FIGURE 2. Synchronization of processes * 

When A receives the WILL TIMING-MARK, he knows that all the Information he 
sent to B before sending the timing nark been delivered, and all the Infonut- 
tlon sent from B to A before turnaround of the timing mark has been delivered. 
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7. Tluf# etliteml applications. 

7.1 lUnMyp%gt» 4#lay. Measure round-trip delay between a process and a 
temlnal or another process. 

7.2 Resynchronisation. Resynchronlzlng an Interaction as described in 
paragraph 4 above. A Is a process Interpreting commands forwarded from a 
terminal by B. When A sees an Illegal command it: 

a. Sends <carrlage retum>, <line feed>, <que8tion mark>. 

b. Sends DO TIMING-^fARK. 

c. Sends an error message. 

d. Starts reading Input and throwing It away until it receives a 
WILL TIMING-MARK. 

e. Resumes Interpretation of Input. 

This achieves the effect of flushing all "type ahead" after the erroneous 
command, up to the point when the user actually saw the question mark. 

7.3 Dual synchronization. The dual of paragraph 7.2. The terminal user 
wants to throw away unwanted output from A. 

a. B sends DO TIMING-MARK, followed by some new command. 

b. B starts reading output from A and throwing It away until it 
receives WILL TIMING-MARK. 

c. B resumes forwarding A's output to the terminal. 

This achieves the effect of flushing all output from A, up to the point 
where A saw the timing mark, but not output generated in response to the 
following command. 
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appendix F 


TELNET EXTENDED OPTIONS - LIST OPTION 

1. Coaaand name and code. 

EXTENDED-OPTIONS-LIST (EXOPL) 255 

2. Command meanings* 

2.1 lAC WILL EXOPL . The sender of this command requests permission to 
begin negotiating, or confirms that It will begin negotiating, TELNET options 
which are on the "Extended Options List." 

2.2 lAC WON'T EXOPL . The sender of this command REFUSES to negotiate, or 
to continue negotiating, options on the "Extended Options List." 

2.3 lAC DO EXOPL . The sender of this command REQUESTS that the receiver 
of this command begin negotiating, or confirms that the receiver of this 
command Is expected to begin negotiating, TELNET options which are on the 
"Extended Options List." 

2.4 lAC DON’T EXOPL . The sender of this command DEMANDS that the receiver 
conduct no further negotiation of options on the "Extended Options List." 

2.5 lAC SB EXOPL <subcoimBand>. The subcommand contains information re¬ 
quired for the negotiation of an option of the "Extended Options List." The 
format of the subcommand Is discussed In paragraph 5 below. 

3. Default . 

WON’T EXOPL, DON'T EXOPL 

Negotiation of options on the "Extended Options List" Is not permitted. 

4. Motivation for the option . Eventually, a 257th TELNET option will be 
needed. This option will extend the option list for another 256 options In 
a manner which Is easy to ImplenM^nt. The option Is proposed now, rather 
than later (probably much later). In order to reserve the option number 
(255). 

5. Description of the option. The EXOPL option has five subcommand codes: 
WILL, WON^T, DO, DON'T, and SB. They have exactly the same meanings as the 
TELNET commands with the same names, and are used In exactly the same way. 

For consistency, these subcommand codes will have the same values as the 
TELNET command codes (250-254). Thus, the format for negotiating a specific 
option on the "Extended Options List" (once both parties have agreed to use 
It) Is: 

lAC SB EXOPL D0/D0N'T/WILL/W0N'T/<optlon code> lAC SE 
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Once both heve agreed to use the specific option specified Iqr <optlon 

code>» sohiflllotlatloii aiay be required. In this case the format to be used 
Is: 

lAC SB EXOPL SB <optlon code> <paraiBeter8> SE lAC SB 
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